From stanzepa@mail2.nai.net Fri Oct 02 19:45:25 1998
Received: from mail2.javanet.com (mail2.javanet.com [205.219.162.11])
	by tapr.org (8.8.5/8.8.5) with ESMTP id TAA22735
	for <aprsnews@tapr.org>; Fri, 2 Oct 1998 19:45:25 -0500 (CDT)
Received: from [209.150.33.52] (ct-hartford-us637.javanet.com [209.150.33.52]) by mail2.javanet.com (8.8.8/8.7) with SMTP id UAA04619 for <aprsnews@tapr.org>; Fri, 2 Oct 1998 20:45:22 -0400 (EDT)
Message-Id: <199810030045.UAA04619@mail2.javanet.com>
X-Mailer: Microsoft Outlook Express for Macintosh - 4.0c (197) 
Date: Fri, 02 Oct 1998 20:25:58 -0400
Subject: [APRSNEWS:148] APRS Coding and HF Opportunity!
From: "Stan Horzepa" <stanzepa@mail2.nai.net>
To: aprsnews <aprsnews@tapr.org>
Mime-version: 1.0
X-Priority: 3
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit

Sender: Bob Bruninga <bruninga@nadn.navy.mil>
Subject: APRS Coding and HF Opportunity!

If you like neat projects, this one is fun and needed.  If you can write
software of any kind, please read:

There is an opportunity for someone to improve our HF performance by a
factor of TEN OR MORE with no change in the protocol!  Since we have the
APRServe system to distribute packets, all we need is ONE OR TWO good HF
receive sites to run some special software to use intelligence to pull the
weak sigs out of the noise and then digi them for all the rest of us!
Here is how:

APRS uses 300 baud on HF packet.  Packets are typically 100 bytes long or
about 800 bits and take 3 seconds to transmit.  Lets use W7LUS our 18
wheel vagabond as an example:

  W7LUS-14>APRS,ECHO,GATE,WIDE,WIDE:@021234z/LAT/LONG$CSE/SPD...

This packet is ONLY received if there is not a single bit error in all 800
bits!  Thus we need about 10-3 bit error rate or better or we get NOTHING.
Most of the time HF is worse than this...
There are several things we can do to improve this:

1) Make packets shorter...
2) Allow some errors and fix em or ignore em...

STEP1.  GATE-ALL.  Each digi field actually takes 7 bytes even for short
calls. AND we want all HF packets widely distributed anyway, so why not
drop ALL the digi fields.  THis saves 4*7 or 28 bytes for a 28%
improvement!  The special software then just always GATES to VHF and the
internet using his local path.  Done.  Easy. 

STEP2.  Error DETECTION:  Of the 72 bytes remaining, MANY are not really
important.  Just keep the last 3 copies of all POSITS for all HF stations
and compare each new one to the old one! Lets look at the separate fields:

  FROM CALL:  Easy to compare slight garbled call to known mobiles
  TOCALL:     Errors ok.  Doesnt matter in APRS
  DIGIS:      Errors ok.  If it aint GATE or WIDE, than make it so
  DATE/TIME:  Ignore it.  Use local time
  LAT/LONG.   Compare to last known position and time since.  if posit
              is within dead reckoned estimate, accept it.  If way off,
              fix obvious errors.  Of DDDMM.HHN  then you can do the
              following:   Ignore HH errors if any
                           DDd should probably be same as before
                             DMM is critical.  Use DR and best guess
                           N,S,E,W are easy to guess if in error
  ICON SYMBOL Just assume same as last packet if different
  CSE         CSE should be within +/- 90 degrees or so of last one
              or just ignore it
  SPD         SPD should be less than 70 MPH or ignore it...
  COMMENTS    just acccept as is.  But put [FIXED] on end so we 
              all know that it is a "fixed" posit.

Now, summing all this up, it looks to me that we could easly make 
sense out of packets with 1 error (doubled our success rate) or
2 errors (quadrupled our success rate) or even 4 errors (8 times success
rate) or even 8 errors (16 times better than we currently do!)

Or another way, is that out of 100 bytes, we only need the 6 bytes of
 ..DMM...DMM for LAT/LONG to be more or less error free.  or only 6 % of
the bytes.  THus, a 16 fold improvement in "procesing gain".

Anyone can accept error packets by just turning PASSALL ON in your TNC.

CAUTION!!!  DO not do this unless you write the special code outlined
above, or you will be destroying the integrity of "error-free" packet
which is assumed to exist throughout the entire APRS network.  One digi or
gate with PASSALL ON can destroy APRS..  Dont do it.  Unless you llike
this idea and ar willing to write some neat code...

You can write this in Basic or anything.  All you are doing is messing
around with the bytes out of the TNC.  Then turning around and
transmitting them via another TNC on to VHF for the rest of the world to
see!   [DO NOT USE the VHF port of an HF TNC with PASSALL ON because the
VHF port will gate ERROR FILLED PACKETS TO VHF and cause a mess.  You
must use two separate TNC's]

Any one wanna play with this?  I would love to do it, but already got too
many other APRS projects to work on..  I wouild prefer that this be
written stand alone to run on an old DOS machine so it can sit in the
closet and just do the job...

bob, WB4APR






From stanzepa@mail2.nai.net Mon Oct 05 18:33:11 1998
Received: from mail2.javanet.com (mail2.javanet.com [205.219.162.11])
	by tapr.org (8.8.5/8.8.5) with ESMTP id SAA08571
	for <aprsnews@tapr.org>; Mon, 5 Oct 1998 18:33:10 -0500 (CDT)
Received: from [209.150.33.182] (ct-hartford-us923.javanet.com [209.150.33.182]) by mail2.javanet.com (8.8.8/8.7) with SMTP id TAA22504 for <aprsnews@tapr.org>; Mon, 5 Oct 1998 19:33:07 -0400 (EDT)
Message-Id: <199810052333.TAA22504@mail2.javanet.com>
X-Mailer: Microsoft Outlook Express for Macintosh - 4.0c (197) 
Date: Mon, 05 Oct 1998 18:58:39 -0400
Subject: [APRSNEWS:151] APRS824 posted
From: "Stan Horzepa" <stanzepa@mail2.nai.net>
To: aprsnews <aprsnews@tapr.org>
Mime-version: 1.0
X-Priority: 3
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit

Sender: Bob Bruninga <bruninga@nadn.navy.mil>
Subject: APRS824 posted

APRS824.zip is now posted on tapr.org in the following directory:

tapr/SIG/aprssig/files/dosstuff/APRSdos

Nothing new, just minor cleanup items.

  * fixes bug with deadreckoning of some WX stations
  * New MAPFIX38 has EDIT-TRIM to bring all edge points inside yellow box
  * Fixes Mic-E dupes on the ALL page
  * FIxed remote U-2K wind and rain anomoly on some U-wk's

Does not fix the undertermined problem that W7LUS was having with 2 comm
ports.  Is he OK now?  I see him on the air.. but donno what he did to fix
it.

bob





From stanzepa@mail2.nai.net Thu Oct 15 19:15:46 1998
Received: from mail2.javanet.com (mail2.javanet.com [205.219.162.11])
	by tapr.org (8.8.5/8.8.5) with ESMTP id TAA21174
	for <aprsnews@tapr.org>; Thu, 15 Oct 1998 19:15:45 -0500 (CDT)
Received: from [209.150.34.223] (ct-hartford-us1516.javanet.com [209.150.34.223]) by mail2.javanet.com (8.8.8/8.7) with SMTP id UAA09633 for <aprsnews@tapr.org>; Thu, 15 Oct 1998 20:15:41 -0400 (EDT)
Message-Id: <199810160015.UAA09633@mail2.javanet.com>
X-Mailer: Microsoft Outlook Express for Macintosh - 4.0c (197) 
Date: Wed, 14 Oct 1998 19:21:31 -0400
Subject: FW: [APRSNEWS:155] Re: [APRSSIG:29046] Re: HF congestion
From: "Stan Horzepa" <stanzepa@mail2.nai.net>
To: aprsnews <aprsnews@tapr.org>
Mime-version: 1.0
X-Priority: 3
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit

Sender: Bob Bruninga <bruninga@nadn.navy.mil>
Subject: Re: [APRSSIG:29046] Re: HF congestion

****       The APRS HF Network is for HF mobiles and stations       ****
****   It is GATED to VHF nets as a courtesy because the VERY SLOW  ****
**** HF traffic can easily be accomodated in the 1200 baud VHF nets ****
****    The reverse, VHF => to HF must be avoided...                ****

Its time for the periodic warning to all APRS users that the HF net can be
killed if VHF users try to go backwards from VHF to HF.  HF at 300 baud
can only handle about 100 users at one packet every 30 minutes.  That is
it.  ANy more and the throughput goes to zero with constant collisions.

There are over 5000 people on VHF all over the country.  If only ONE
PERSON IN 100 or only 1% of APRS users decide to use a VHF to HF gateway,
then the HF net becomes CLOGGED AND USELESS TO EVERYONE.

Please remember these guidelines:

1)  Unless your station is actively involved in something of NATIONAL
interest, do NOT use a path on VHF that includes GATE ever.

2)  Do NOT use any VHF=>GATE path for WX stations or digipeaters!

3)  Do NOT use any VHF=>GATE path for local mobils

4)  If you are on a big trip, traveling cross country, and need to
communicate and do not have HF, then you might consider adding your QRM to
the very fragile and narrowband HF network.

5)  Listen before you transmit if possible.  Listen to 10151 LSB and do
NOT use a VHF-HF path if the channel is more than 50% full...
(statistically, an APRS frequency must be clear 67% of the time to avoid a
reduction of throughput due to collisions.)

6)  Read my HF.TXT in the APRSdos README directory...

De WB4APR, Bob





